Introduction
You can see below a simple overview of a development department's domain.
The people, teams, tools and applications it interacts with, uses and builds.
A development manager needs to consider each of these entities and how each can be best managed - so for example how we educate (wrt our processes) and communicate with project managers, how we define processes and standards for using tools.
The rest of this page discusses each entity and how I would manage it.
Each section below has a sub-section entitled 'MI' - Management Information. I think it's important to track how we are doing against our targets and to evidence that BAU activities are being completed.
So I generally use tools or spreadsheets to track this - these are useful to me and also useful as a way of demonstrating to others (like my boss) that I am running a tight ship and that things are under control.
Domain Overview
Customers
These people are obviously key to us - given our main purpose is to delight them with our delivery.
As a development manager I would be making sure I was talking to these people on a regular basis both about current projects and future possibilities - their own ideas and ideas coming from IT.
To do this I would need:
Development reporting setup (agile or traditional) - which I would be reviewing with my teams on a regular basis.
Processes and presentations written up about how PMs and the like engage with us - I make sure I run through these with any new PMs and that they are available on our wiki.
A communication plan (an idea I've taken from project management) that details for all the people and groups we deal with the what, when, where, why and how of our communication with them.
MI
Assuming we use a tool like Jira to manage developments, it can produce various charts covering velocity, burn down etc. - and these can be aggregated.
I can also show compliance with our communications plan - typically I just have a table showing the different activities, the cells contain due dates and are green if the tasks have been completed and red if they are in the past and not complete. Quite useful for me (and my manager).
Our People
All the basic HR documentation needs to be in place:
- Role descriptions
- Any processes we need - for example, out of hours support.
and per individual:
- Internal CV / profile (e.g. Office 365)
- Objectives
- Appraisals c/w training plan
I'd typically have 1-1s with my direct reports every month and I always make an effort to understand their current situation (outside and inside work), aspirations etc.
I take a genuine interest in all my staff and I believe that leads to loyalty.
MI
Similar to the comms plan above I demonstrate I am completing these activities by having them represented in a table with due dates and colouring each cell green when complete.
Projects
Assuming a project has complexity to it, I like to assess a project during initiation, particularly wrt risk and deciding how it will be approached - so what agile practices we can sensibly use (all of them if possible) and what deliverables we should produce.
Assuming documents are required - I'd want them stored in a document management system (eRoom, Sharepoint) for all the obvious benefits that gives.
Overall delivery of a project is the responsibility of the PM - but with me responsible for delivery of the development.
I've covered how I would report on delivery of the development and how I would generate MI on that under the 'Customers' section above.
I'd expect to have access to project status reports to understand the PM's view of project status and see all the normal project and PM deliverables (change requests, issues and risk logs etc.)
I'd also be talking tithe SCRUM Masters and reviewing burn down and velocity stats.
On non-agile projects I'd take a particular interest in change requests as these would impact my resourcing and I would also take an interest in the risk and issues logs:
To see if I could add value wrt to any of the current entries.
To advise the PM of any risks or issues I thought needed adding on.
MI
The PM is responsible for project reporting (so in PRINCE2 terms highlight reports) with my teams providing checkpoint reports, I also like to report my view on progress / risks / issues / changes to my bosss.
You can drive MI out of this by keeping the info (so you can reveal trends) and rolling stats up (so you can see the big picture but also drill down).
Some packages e.g. PPM type packages go some way towards this but typically only provide snapshot info and not trend - so I typically export data to Excel or a database so I can get the trends I value.
So for example you can see if a project's risk profile is increasing or decreasing, on non agile project the amount of change etc.
Applications
I've worked for a number of larger companies where development has owned several hundred applications / services.
It's obviously important that we have an appropriate set of documentation for each (e.g. overview, architecture diagram, support documents), clarity as to location of production source code etc.
It's also sensible to understand which staff are knowledgeable about the app and hence if we have any SPODs (single points of dependency (failure)).
I generally setup a basic Service Catalogue - a spreadsheet or database to track how well we meet the above and where the gaps are.
I tag apps in various ways (e.g. business criticality, number of users) to help understand the risk associated with any gaps and hence drive a plan to address the gaps.
I have seen in some of the companies I have worked in architecture departments try (and fail) to setup comprehensive Service Catalogues using tools like Trove. The problem is the more you analyse what you would like to do in terms of cataloguing apps the more complicated (and unachievable) it becomes, so I take a pragmatic / agile approach and document the basics and grow from there, with the activities steered according to priority.
MI
MI can be generated from the service catalogue to show what gaps (and risk) we have and we can chart our progress in reducing both.
So, as a simple example, we might have a chart detailing how many SPODs we have for our entire service catalogue with the chart showing the number reducing as we take steps to train people.
Typically these charts are pivots / cubes so we can filtered according to certain tags e.g. business criticality.
We also define and agree (with the business owners) roadmaps for significant apps.
Enablers
Typically we would define standards (or refer to industry best practice). We would also define processes for ensuring compliance e.g. standards checking linked to CI.
Standards / QA are needed at various levels e.g. everything from language standards to design patterns and templated code for, for example, notifying support of an application error.
It is also important we control the tools the teams are using - we want teams to be cross skilled as completely as possible and this is more achievable with a fairly limited toolset.
Part of this control would involve the sun-setting of tools, the restriction of use of some tools and building into individual's objectives the gaining of skills (to aid cross skilling).